Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000025_owner-urn-ietf _Mon Nov 4 15:06:47 1996.msg

Internet Message Format | 1997-02-19 | 6KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA08830 for urn-ietf-out; Mon, 4 Nov 1996 15:06:47 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA08825 for <[e-mail]>; Mon, 4 Nov 1996 15:06:40 -0500
Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA25851  (mail destined for [e-mail]); Mon, 4 Nov 96 15:06:38 -0500
Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id PAA08313; Mon, 4 Nov 1996 15:06:37 -0500
Date: Mon, 4 Nov 1996 15:06:37 -0500
Message-Id: <[e-mail]>
From: "Karen R. Sollins" <[e-mail]>
To: [e-mail]
Subject: Re: [URN] some comments
Sender: [e-mail]
Precedence: bulk
Reply-To: "Karen R. Sollins" <[e-mail]>
Errors-To: [e-mail]

Let me try once more...

There are three core functions that are generally provided by "names":
identification, location, and mnemonics or semantics.  Let me describe
each separate.  In this context, all have meaning only with respect to
resources.

Identification allows the assigner of the name to declare the
distinctiveness of a resource from other resources, from the
perspective of the assigner of the name.  This allows someone else to
recognize this distinction or lack thereof as intended by the name
assigner.  Generally, all naming schemes provide this in some form or
other.

Location allows the assigner to declare something about how to locate
or find the resource.  In an abstract sense it can be seen as
"location", but the meaning of location is left to the interpretation
of the supporting infrastructure.  A different way of saying this is
that it is the input to the supporting protocol elements.  Again,
generally, at least in computer systems, all naming schemes provide
this in some form or other.

Mnemonics or semantics allows the assigner to include something
"meaningful" to potential clients, such as ways to remember the name,
or perhaps something about the nature of the resource (an extension
defining the language in which the resource is encoded, an algorithm
that was used in it, it's functionality, or perhaps its relationship to
other resources, e.g. versioning).  Not all naming schemes provide
this.  Human friendly schemes tend to do much more than machine
friendly ones.

Now, let's step back and look at our environment.  We are talking
about a situation in which there are "layers of abstraction".  At
"our" layer, the entities to be named are resources.  Resources will
be supported by an infrastructural suite, including (although I may
have missed some) storage services (file systems, oodbms, object
repositories, etc.), computation engines, access methods, access
constraint methods, communications protocols, and perhaps others.  So,
for example, at the present the infrastructure may be provided by
publicly accessible unix file systems, NT file systems, etc, as well
as a collection of transport protocols such as HTTP, NNTP, FTP,
Z39.50, etc.  These are not part of our layer of abstraction, but
rather are what we use to realize them.  These things in turn are
themselves supported by lower level abstractions.  The same issues of
naming listed above apply to each of the layers.

After much more than 2 yrs we have chosen by consensus a particular
model with respect to naming within our layer.  That model for the
most part separates the three functions and realizes them separately.
In the URI architecture (not Tim B-L's idea of URIs, but that of the
URI WG consensus), these functions are separately provided by three
components of the architecture.  Identification is provided by URNs,
location by URLs, and semantics by URCs.  That is what was agreed to
by consensus of the working group.  That is what is laid out in the
introductions to both the URN and URL requirements documents that were
also agreed to by the WG.  Such a layering architecture also
recognizes that there are different layers of abstraction and that at
least abstractly one goes through the exercise repeatedly (and not
just at the layers at which we are working) of taking an identifier
and using it to either learn something about distinctions or lack
thereof in the intention of the name assigner or perhaps semantics,
and/or alternatively "resolving" or "binding" it, by translating it
into something for which the only intention is that it be handed to
some piece of the infrastructure to "do its thing" on.  For this
resolution or binding process one might use similar mechanisms at
different layers of abstraction, such as table lookup or recourse to
servers using the same query protocol in order to request resolution.
But that in no way means that the same abstractions are being
identified, learned about or resolved.  Given our choice of
separation, we, in this working group, have set about to design a
first mechanism to provide the binding of name to location.

Let me recommend to you an extremely well-written short paper on the
subject, "On the Naming and Binding of Network Destinations" by Jerry
Saltzer.  This was originally published in 1983 (yes, that was long
before the URI WG was formed :-), so its examples are
from that era.  The concepts are completely applicable to this
discussion.  This is not a new problem, nor is the model of
distinguishing between name and address a new solution.  It was issued
as RFC 1498 (informational) in 1993.

Two additional relevant references (from Saltzer's paper) that I also
recommend to you are:

Shoch, John F., "Inter-Network Naming, Addressing, and Routing,"
       IEEE Proc. COMPCON Fall 1978, pp. 72-79. Also in Thurber, K.
       (ed.), Tutorial: Distributed Processor Communication
       Architecture, IEEE Publ. #EHO 152-9, 1979, pp. 280-287.

Sunshine, Carl A., "Addressing Problems in Multi-Network
       Systems", to appear in Proc. IEEE INFOCOM 82, Las Vegas, Nevada,
       March 30 - April 1, 1982.

            Karen Sollins